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Abstract 
This document describes the applicability of the several protocols 
developed under the signalling transport framework. A description of 
the main issues regarding the use of the Stream Control Transmission 
Protocol (SCTP) and an explanation of each adaptation layer for 


transport of telephony signalling information over IP infrastructure 
are given. 
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1. Introduction 


This document is intended to describe how to transport telephony 
signalling protocols, used in classic telephony systems, over IP 
networks. As described in [RFC2719], the whole architecture is 
called SIGTRAN (Signalling Transport) and is composed of a transport 
protocol (SCTP) and several User Adaptation Layers (UALS). The 
transport protocol SCTP has been developed to fulfill the stringent 
requirements of telephony signalling networks [RFC3257]. The set of 
UALs has also been introduced to make it possible for different 
signalling protocols to use the SCTP layer. 


1.1. Scope 
The scope of this document is the SIGTRAN user adaptation layers and 


SCTP protocols and how they are used to transport telephony 
signalling information over IP networks. 
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1.2. Terminology 
The following terms are commonly identified in related work: 
Association: SCTP connection between two endpoints. 
Stream: A uni-directional logical channel established within an 
association, within which all user messages are 
delivered in sequence except for those submitted to the 


unordered delivery service. 


SPU: Signalling protocol user, the application on top of the 
User adaptation layer. 


CTSP: Classical Telephony Signalling Protocol (examples 
include: MTP level 2, MTP level 3, and SCCP). 


UAL: User Adaptation Layer, the protocol that encapsulates 
the upper layer telephony signalling protocols that are 
to be transported over SCTP/IP. 


ISEP: IP Signalling Endpoint, an IP node that implements SCTP 
and a User adaptation layer. 


SP: Signalling Point. 

1.3. Contributors 
The following people contributed to the document: L. Coene (Editor), 
M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, M. 
Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor, and L. Ong. 


2. SIGTRAN Architecture 


The SIGTRAN architecture describes the transport of signalling 
information over IP infrastructure. 
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Telephony signalling transport over IP normally uses the following 


architecture: 
Telephony Signalling Protocol 
Sp Se Ser eo GEE + 
User Adaptation Layers 
$ O ER + 
ha eS SS O ee oS See See + 
|Stream Control Transmission Protocol | 
| (SCTP) | 
a a + 


Internet Protocol (IPv4/IPv6) 
Figure 1: Telephony SIGnalling TRANsport Protocol Stack 
The components of the protocol stack are: 


1. Adaptation layers used when the telephony application needs to 
preserve an existing primitive interface (e.g., management 
indications or data operation primitives for a particular 
user/application protocol). 

2. SCTP, specially configured to meet the telephony application 
performance requirements. 

3. The standard Internet Protocol. 


The telephony signalling protocols to be transported can be: 


[RFC3332] SS7 MTP3 users: SCCP, ISUP, TUP... 

[RFC3331] SS7 MTP2 users: MTP3 

[RFC3868] SST SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... 
[RFC3057] ISDN Q.921 users: Q.931 

[RFC3807] V5.2 / DSS1 


000000 


The user adaptation layers (UALS) are a set of protocols that 
encapsulate a specific signalling protocol to be transported over 
SCTP. The adaption is done in a way that the upper signalling 
protocols, which are relayed, remain unaware that the lower layers 
are different from the original lower telephony signalling layers. 

In that sense, the upper interface of the user adaptation layers 
needs to be the same as the upper layer interface is to its original 
lower layer. If a MTP user is being relayed over the IP network, the 
related UAL used to transport the MTP user will have the same upper 
interface as MTP has. 
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The Stream Control Transmission Protocol was designed to fulfill the 
stringent transport requirements that classical signalling protocols 
have and is therefore the recommended transport protocol to use for 
this purpose. 


SCTP provides the following functions: 


Reliable Data Transfer 

Multiple streams to help avoid head-of-line blocking 
Ordered and unordered data delivery on a per-stream basis 
Bundling and fragmentation of user data 

Congestion and flow control 

Support for continuous monitoring of reachability 
Graceful termination of association 

Support of multi-homing for added reliability 

Protection against blind denial-of-service attacks 
Protection against blind masquerade attacks 


0000000000 


SCTP is used as the transport protocol for telephony signalling 
applications. Message boundaries are preserved during data transport 
by SCTP, so each UAL can specify its own message structure within the 
SCTP user data. The SCTP user data Can be delivered by the order of 
transmission within a stream (in sequence delivery) or unordered. 


SCTP can be used to provide redundancy at the transport layer and 
below. Telephony applications needing this level of redundancy can 


make use of SCTP’s multi-homing support. 


SCTP can be used for telephony applications where head-of-line 


blocking is a concern. Such an application should use multiple 
streams to provide independent ordering of telephony signalling 
messages. 


3. Issues for Transporting Telephony Signalling over SCTP 


Transport of telephony signalling requires special considerations. 
In order to use SCTP, an implementation must take special care to 
meet the performance, timing, and failure management requirements. 


3.1. Congestion Control 


The basic mechanism of congestion control in SCTP has been described 
in [RFC2960]. SCTP congestion control sometimes conflicts with the 
timing requirements of telephony signalling application messages 
which are transported by SCTP. During congestion, messages may be 
delayed by SCTP, thus sometimes violating the timing requirements of 
those telephony applications. 
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In an engineered network (e.g., a private intranet), in which network 
capacity and maximum traffic are very well controlled, some telephony 
signalling applications may choose to relax the congestion control 
rules of SCTP in order to satisfy the timing requirements. In order 
to do this, they should employ their own congestion control 
mechanisms. This must be done without destabilizing the network; 
otherwise, it would lead to potential congestion collapse of the 
network. 


Some telephony signalling applications may have their own congestion 
control and flow control techniques. These techniques may interact 
with the congestion control procedures in SCTP. 


3.2. Detection of Failures 


Often, telephony systems must have no single point of failure in 
operation. 


The UAL must meet certain service availability and performance 
requirements according to the classical signalling layers they are 
replacing. Those requirements may be specific for each UAL. 


For example, telephony systems are often required to be able to 
preserve stable calls during a component failure. Therefore, error 
situations at the transport layer and below must be detected quickly 
so that the UAL can take appropriate steps to recover and preserve 
the calls. This poses special requirements on SCTP to discover 
unreachability of a destination address or a peer. 


3.2.1. Retransmission TimeOut (RTO) Calculation 


The SCTP protocol parameter RTO.Min value has a direct impact on the 
calculation of the RTO itself. Some telephony applications want to 
lower the value of the RTO.Min to less than 1 second. This would 
allow the message sender to reach the maximum 
number-of-retransmission threshold faster in the case of network 
failures. However, lowering RTO.Min may have a negative impact on 
network behaviour [ALLMAN99]. 


In some rare cases, telephony applications might not want to use the 
exponential timer back-off concept in RTO calculation in order to 
speed up failure detection. The danger of doing this is that, when 
network congestion occurs, not backing off the timer may worsen the 
congestion situation. Therefore, this strategy should never be used 
on the public Internet. 


It should be noted that not using delayed SACK will also increase the 
speed of failure detection. 
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3.2.2. Heartbeat 


For faster detection of (un)availability of idle paths, the telephony 
application may consider lowering the SCTP parameter HB.interval. It 
should be noted this might result in a higher traffic load. 


3.2.3. Maximum Number of Retransmissions 


Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters 
to lower values will speed up both destination address and peer 
failure detection. However, if these values are set too low, the 
probability of false fault detections might increase. 


3.3. Shorten End-to-End Message Delay 


Telephony applications often require short end-to-end message delays. 
The method described in Section 3.2.1 for lowering RTO may be 
considered. The different paths within a single association will 
have a different RTO, so using the path with the lowest RTO will lead 
to a shorter end-to-end message delay for the application running on 
top of the UALs. 


3.4. Bundling Considerations 


Bundling small telephony signalling messages at transmission helps 
improve the bandwidth usage efficiency of the network. On the 
downside, bundling may introduce additional delay to some of the 
messages. This should be taken into consideration when end-to-end 
delay is a concern. 


3.5. Stream Usage 


Telephony signalling traffic is often composed of multiple, 
independent message sequences. It is highly desirable to transfer 
those independent message sequences in separate SCTP streams. This 
reduces the probability of head-of-line blocking in which the 
retransmission of a lost message affects the delivery of other 
messages not belonging to the same message sequence. 


4. User Adaptation Layers 


Users Adaptation Layers (UALS) are defined to encapsulate different 
signalling protocols for transport over SCTP/IP. 


There are UALs for both access signalling (DSS1) and trunk signalling 


(SS7). A brief description of the standardized UALs follows in the 
next sub-sections. 
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The delivery mechanism in several UALS supports: 


o Seamless operation of UALS user peers over an IP network 
connection. 

o The interface boundary that the UAL user had with the traditional 
lower layer. 

o Management of SCTP transport associations and traffic between SGs 
and ISEPs or two ISEPs 

o Asynchronous reporting of status changes to management. 


Signalling User Adaptation Layers have been developed for both Access 
and Trunk Telephony Signalling. They are defined as follows. 


Access Signalling: This is the signalling that is needed between an 
access device and an exchange in the core network in order to 
establish, manage, or release the voice or data call paths. Several 
protocols have been developed for this purpose. 


Trunk Signalling: This is the signalling that is used between the 
exchanges inside the core network in order to establish, manage, or 
release the voice or data call paths. The most common protocols used 
for this purpose are known as the SS7 system, which belongs to the 
Common Channel Signalling (CCS) philosophy. The SS7 protocol stack 
is depicted below: 


+------ 4+----- 4+------- +- -+------- 4+------ 4+----- 4+------ + 
| | | | | | MAP | CAP | INAP | 
+ + RANAP .| BSSAP +------------------- + 
| IsUP | TUP | | | | TCAP | 
+ | +-------------------------------------- + 
| | | SCCP | 
AZ + 
| MTP3 | 
AZ + 
| MTP2 | 
AZ + 
| MTP1 | 
AZ + 


Figure 2: SS7 Protocol Stack 
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The Telephony Signalling Protocols to be transported with the already 
designed UALS are: 


ISDN Q.921 Users: Q.931 

V5.2/DSS1 

DPNSS/DASS2 [RFC4129] 

SS7 MTP3 Users: SCCP, ISUP, TUP 

SS7 MTP2 Users: MTP3 

SS7 SCCP Users: TCAP, RANAP, BSSAP, 


000000 


Two main scenarios have been developed to use the different UALS for 
IP Signalling Transport: 


1. Intercommunication of traditional Signalling transport nodes and 
IP based nodes. 


Traditional Telephony 
Telephony Signalling 
KKKKKKKKK Signalling KKKKKKKKKK over IP KKKKKKKK 
* SEP  *---------------- * §G  *=-------------- * ISEP * 
KKKKKKKKK KKKKKKKKKK KKKKKKKK 
4+------- + 4+------- + 
|SigProt | |SigProt | 
4+------- + 4+----+----+ 4+------- + 
| | | [UAL | | UAL | 
| | | +----+ +------- + 
| TTST | TTST|SCTP | | SCTP | 
4+----+ 4+------- + 

| | | | 12 | | IP | 
4+------- + 4+--------- + 4+------- + 

SEP = Signalling Endpoint 

SG - Signalling Gateway 

ISEP = IP Signalling Endpoint 

SigProt - Signalling Protocol 

TTSP - Traditional Telephony Signalling Protocol 

UAL = User Adaptation Layer 


SCTP 


Stream Control Transport Protocol 
Figure 3: General Architecture of SS7-IP Interworking 
This is also referred to as SG-to-AS communication. AS is the name 


that UAL usually gives to the ISEP nodes. It stands for Application 
Server. 
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2. Communication inside the IP 


KKKKKKKKK 


* ISEP 


KKKKKKKKK 


4+------- + 
|SigProt | 
4+------- + 
| UAL | 
4+------- + 
| SCTP | 
4+------- + 
| IP | 
4+------- + 


Figure 4: 


This is also referred to as IPSP communication. 


Signalling Point and describes 
IP-based node. 


The first scenario is applied for both types of signalling 


and trunk signalling). On the 


Telephony Signalling over SCTP AS 


February 2006 


network. 


Telephony 
Signalling 
over IP 


KKKKKKKKK 


ISEP * 


KKKKKKKKK 


4+------- + 
|SigProt | 
4+------- + 
| UAL | 
4+------- + 
| SCTP | 
4+------- + 
| īp | 
4+------- + 


General Architecture of Intra-IP Communication 


IPSP stands for IP 
the role that the UAL plays on an 


(access 
other hand, the peer-to-peer basis can 


only be used for trunk signalling. 


The SIGTRAN WG has developed UALS to transport the following Access 


4.1. Access Signalling 
Signalling protocols: 
o ISDN Q.931 
6, Vd: 2 
o DPNSS/DASS2 
4.1.1. IUA (ISDN Q.921 User Adaptation) 
UAL: IUA (ISDN 0.921 User Adaptation) 


This document supports both ISDN Primary Rate Access 
including the support for both point-to-point 


Basic Rate Access (BRA) 


and point-to-multipoint modes of communication. 
includes Facility Associated Signalling 
and NFAS with backup D channel. 


Associated Signalling (NFAS), 
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(PRA) as well as 


This support 


(FAS), Non-Facility 
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It implements the client/server architecture. The default 


orientation is for the 


SG to take on the role of server while the 


ISEP is the client. The SCTP (and UDP/TCP) Registered User Port 
Number Assignment for IUA is 9900. 


Examples of the upper layers to be transported are Q.931 and QSIG. 


The main scenario supported by this UAL is the SG-to-ISP 
communication where the ISEP role is typically played by a node 
called an MGC, as defined in [RFC2719]. 


Figure 5: 


The SCTP (and UDP/TCP) 
is 9900. 


ISDN KKKKKK IP KKKKKKK 
SS A ee * SG oa SS == eX MGC * 
KKKKKK KKKKKKK 

4+----- + 

(NIF) |Q.931| 

4+---------- + 4+----- + 

| | IUA| | IUA | 

+=---+ 4+----- + 

Q.921|SCTP | |SCTP | 

| +----+ +----- + 

| | IP | | IP | 

4+----- 4+----+ 4+----- + 


Nodal Interworking Function 

Private Branch Exchange 

Stream Control Transmission Protocol 
ISDN User Adaptation Layer Protocol 


ISDN-IP Interworking using IUA 


Registered User Port Number Assignment for IUA 


The value assigned by IANA for the Payload Protocol Identifier in the 
SCTP Payload Data chunk is "1". 
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4.1.2. V5UA (V5.2-User Adaptation) Layer 
UAL: V5UA (V5.2-User Adaptation) 


V5UA is an extension from the IUA layer with the modifications needed 
to support the differences between Q.921/0.931, and V5.2 layer 
2/layer 3. It supports analog telephone access, ISDN basic rate 
access and ISDN primary rate access over a V5.2 interface. It is 
typically implemented in an interworking scenario with SG. 


KKKKKK V5 2 KKKKKK IP KKKKKKK 
* AN *--------------- * SG *-------------- * MGC * 
KKKKKK KKKKKK KKKKKKK 
+----- + +----- + 
|v5.2 | (NIF) |v5.2 | 
Yoo + +---------- + +----- + 
| | | | V5UA| |V5UA | 
| +----+ +----- + 
| LAPV5 | | LAPV5|SCTP | |SCTP | 
+----+ Yoo + 
| IP + | IP | 
Yoo + Yoo +o---+ Ho + 
AN - Access Network 
NIF - Nodal Interworking Function 
LAPV5 - Link Access Protocol for the V5 channel 
SCTP - Stream Control Transmission Protocol 


Figure 6: V5.2-IP Interworking using V5UA 


The SCTP (and UDP/TCP) Registered User Port Number Assignment for 
V5UA is 5675. 


The value assigned by IANA for the Payload Protocol Identifier in the 
SCTP Payload Data chunk is "6". 
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4.1.3. DUA (DPNSS/DASS User adaptation) Layer 
UAL: DUA (DPNSS/DASS2 User Adaptation) 
The DUA is built on top of IUA and defines the necessary extensions 


to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private 
Network Signalling System and DASS2 for Digital Access Signalling 


System 2. 

KKKKKK DPNSS KKKKKK IP KKKKKKK 
*PBX *--------------- * SG *-------------- * MGC * 
KKKKKK KKKKKK KKKKKKK 
+----- + +----- + 
| DPNSS | (NIF) |DPNSS | 
MES [Unas ;] 
ooo + oo +o---+ too + 
A | ova] | Dua | 
| DPNSS | | DPNSS+----+ +----- + 
[ee | | 12 |scTP| |SCTP | 
| | | +----+ +----—- + 
|| | | ws | 12 | 
Yoo + Yoo +----+ Yoo + 

PBX - Private Branch eXchange 

NIF - Nodal Interworking Function 

SCTP - Stream Control Transmission Protocol 

DUA - DPNSS User Adaptation Layer Protocol 


Figure 7: DPNSS-IP Interworking using DUA 


The value assigned by IANA for the Payload Protocol Identifier in the 
SCTP Payload Data chunk is "10". 


4.2. Network Signalling 


The SIGTRAN WG has developed UALs to transport the following SS7 
protocols: 


o MTP2 Users: MTP3 


o MTP3 Users: ISUP, TUP, SCCP 
o SCCP Users: TCAP, RNSAP, RANAP, BSSAP, 
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4.2.1. MTP lvl3 over IP 
UALS: 


o M2UA (SS7 MTP2 User Adaptation [RFC3331]) 
o M2PA (SS7 MTP2-User Peer-to-Peer Adaptation [RFC4165]) 


4.2.1.1. M2UA (SS7 MTP2-User Adaptation) Layer 


M2UA protocol is typically used between a Signalling Gateway (SG) and 
Media Gateway Controller (MGC). The SG will terminate up to MTP 
Level 2, and the MGC will terminate MTP Level 3 and above. [In other 
words, the SG will transport MTP Level 3 messages over an IP network 
to an MGC. 


MTP3 and MTP3b are the only SS7 MTP2 User protocols that are 
transported by this UAL. 


The SG provides an interworking of transport functions with the IP 
transport to transfer MTP2-User signalling messages with an 
Application Server (e.g., MGC) where the peer MTP2-User exists. 


KKKKKK SS7 KKKKKK IP KKKKKKK 
*SEP *----------- * SG *------------- * MGC * 
KKKKKK KKKKKK KKKKKKK 
+----+ +----+ 
| S7UP | | S7UP | 
+----+ +----+ 
|MTP3 | |MTP3 | 
| | (NIF) | | 
+----+ +----+----+ +----+ 
| | | |M2UA| |M2UA| 
+----+ +----+ 

sal PE oe | SCTP | 

| +o---+ ++ 
| | | [IP | [IP | 
+----+ +--------—- + +----+ 
MGC - Media Gateway Controller 
SG - Signalling Gateway 
SEP - SS7 Signalling Endpoint 
NIF - Nodal Interworking Function 
IP - Internet Protocol 


SCTP 


Stream Control Transmission Protocol 


Figure 8: SS7-IP Interworking using M2UA 
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The SCTP (and UDP/TCP) Registered User Port Number Assignment for 
M2UA is 2904. 


The value assigned by IANA for the Payload Protocol Identifier in the 
SCTP Payload Data chunk is "2". 


4.2.1.2. M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) 
M2PA protocol is used between SS7 Signalling Points employing the MTP 
Level 3 protocol. The SS7 Signalling Points may also use standard 
SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 


3 signalling messages. 


Both configurations: communication of SS7 and IP with SG and 
communication between ISEPs are possible. 


Connection of SS7 and IP nodes: 


KKKKKKKK SS7 KKEKKKKKKKKKKKKK IP KKKKKKKK 
* SEP *-------- * SG *-------- * IPSP * 
KKKKKKKK KKEKKKKKKKKKKKKK KKKKKKKK 
4+------ + 4+------ + 
| TCAP | | TCAP | 
+------ + +------ + 
| sccp | | sccp | 
4+------ + 4------------- + 4+------ + 
| MTP3 | | MTP3 | | MTP3 | 
4+------ + 4+------ 4+------ + 4+------ + 
| | | | M2PA | | M2PA | 
| | | +-----—- + +-----—- + 
| MTP2 | | MTP2 | SCTP | | scTP | 
| | | +-----—- + +-----—- + 
| | | [EE | | TP | 
4+------ + 4+------ +------ + +------ + 
SEP - SS7 Signalling Endpoint 


Figure 9: SS7-IP Interworking with M2PA 
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Communication between two IP nodes: 


KKKKKKKK IP KKKKKKKK 
* IPSP *-------- * IPSP * 
KKKKKKKK KKKKKKKK 
+------ + +------ + 
| TCAP | | TCAP | 
+------ + +------ + 
| sccP | | sccP | 
+------ + +------ + 
| MTP3 | | MTP3 | 
+------ + +------ + 
| M2PA | | M2PA | 
+------ + +------ + 
| scTP | | scTP | 
+------ + +------ + 
| IP | | IP | 
4+------ + 4+------ + 

IP - Internet Protocol 

IPSP - IP Signalling Point 

SCTP - Stream Control Transmission Protocol 


Figure 10: Intra-IP Communication using M2PA 


These figures are only an example. Other configurations are 
possible. For example, IPSPs without traditional SS7 links could use 
the protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a 
network with all IP links. 


Another example is that two SGs could be connected over an IP network 
to form an SG mated pair, similar to the way STPs are provisioned in 


traditional SS7 networks. 


The SCTP (and UDP/TCP) Registered User Port Number Assignment for 
M2PA is 3565. 


The value assigned by IANA for the Payload Protocol Identifier in the 
SCTP Payload Data chunk is "5". 
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4.2.1.3. Main Differences between M2PA and M2UA 


o M2PA: IPSP processes MTP3/MTP2 primitives. 

o M2UA: MGC transports MTP3/MTIP2 primitives between the SG’s MTP2 
and the MGC’s MTP3 (via the NIF) for processing. 

o M2PA: SG-IPSP connection is an SS7 link. 

o M2UA: SG-MGC connection is not an SS7 link. It is an extension of 
MTP to a remote entity. 


4.2.2. M3UA (SS7 MTP3 User Adaptation) Layer 
UAL: M3UA (SS7 MTP3 User Adaptation) 


M3UA protocol supports the transport of any SS7 MTP3-User signalling 
such as TUP, ISUP, and SCCP over IP using the services of SCTP. 


Interconnection of SS7 and IP nodes: 


KKKKKKKK SS7 KKEKKKKKKKKKKKKKKK IP KKKKKKKK 
* SEP  *--------- * SGP ko * ASP * 
KKKKKKKK KKEKKKKKKKKKKKKKKK KKKKKKKK 
+------ + +--------------- + +------ + 
| IsuP | | (NIF) | | IsuP | 
+------ + +------ + +------ + +------ + 
| MTP3 | | MTP3 | | m3ua | | M3UA | 
+-----—- | +-----—- +-+-----—- + +-----—- + 
| MTP2 | | MTP2 | | scre | | scTP | 
+------ + +------ + +------ + +------ + 
| m | | ur | | IP | | IP | 
+------ + +------ + +------ + +------ + 

SEP - SS7 Signalling End Point 

SCTP - Stream Control Transmission Protocol 

NIF - Nodal Interworking Function 


Figure 11: SS7-IP Interworking using M3UA 
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Communication between two IP nodes: 


M3UA uses a client-server architecture. 
ISEP acts as the client and initiate the 
The port reserved by IANA is 2905. 
SG should listen for possible client 


SG. 
the 


The 


MS. 


Abad 


UAL: 


KKKKKKKK 


+ ER SPs CK 
AK Kk 


Figure 12: 


assigned payload protocol identifier 


SUA (SS7 SCCP User Adaptation) 


SUA (SS7 SCCP User Adaptation) 
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Layer 
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KKKKKKKK 


~--------- * IPSP * 


KKKKKKKK 


Intra-IP Communication using M3UA 


It is recommended that the 
SCTP associations with the 
This is the port upon which 
connections. 


for the SCTP DATA chunks is 


SUA protocol supports the transport of any SS7 SCCP-User signalling 


such as MAP, 
SCTP. 


INAP, SMS, BSSAP, 


or RANAP over IP using the services of 
Each of the applications using SUA has its own set of timing 


requirements that can be found in its respective standards documents. 
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Possible configurations are showed in the pictures below. 


- Interconnection of SS7 and IP: 


KKKKKKKK KKEKKKKKKKKKKKKK KKKKKKKK 
* SEP * SST * * IP > * 
AD Oty AS Saas e es $ SG NSS RRS As ASP. S 
* STP * * * * * 
KKKKKKKK KKEKKKKKKKKKKKKK KKKKKKKK 
$ 4+------ + 
| suaP | | suap | 
4+------ + 4+------ Ho + $ === - + 
| sccp | | sccp | sua | | sua | 
4+------ + 4+------ 4+------ + 4+------ + 
MTP3 MTP3 | SCTP SCTP 
| | | | | | | 
+------ + 4+------ 4+------ + 4+------ + 
| MTP2 | | MTP2 | IP | | IP | 
4 - + 4+------ 4+------ + 4+------ + 


SUAP - SCCP/SUA User Protocol (TCAP, for example) 
STP - SS7 Signalling Transfer Point 


Figure 13: SS7-IP Interworking using SUA 


- IP Node to IP Node communication: 


KKKKKKKK KKKKKKKK 
* * IP * * 
* IPSP *-------- * IPSP * 
* * * * 
KKKKKKKK KKKKKKKK 
+------ + +------ + 
| SUAP | | SUAP | 
+------ + +------ + 
| sua | | sua | 
+------ + +------ + 
| scTP | | scTP | 
+------ + +------ + 
| IP | | IP | 
+------ + +------ + 


Figure 14: Intra-IP Communication using SUA 
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IANA has registered SCTP Port Number 14001 for SUA. It is 
recommended that SGs use this SCTP port number for listening for new 
connections. The payload protocol identifier for the SCTP DATA 
chunks is "4", 


5. Security Considerations 


UALs are designated to carry signalling messages for telephony 
services. As such, UALS must involve the security needs of several 
parties: the end users of the services, the network providers, and 
the applications involved. Additional requirements may come from 
local regulation. Although some security needs overlap, any security 
solution should fulfill all the different parties’ needs. See 
specific Security Considerations in each UAL Technical specification 
for details (for general security principles of SIGTRAN, see 
[RFC3788]). 


SCTP only tries to increase the availability of a network. SCTP does 
not contain any protocol mechanisms directly related to communication 
security, i.e., user message authentication, integrity, or 
confidentiality functions. For such features, SCTP depends on 
security protocols. In the field of system security, SCTP includes 
mechanisms for reducing the risk of blind denial-of-service attacks 
as described in Section 11 of [RFC2960]. 


This document does not add any new components to the protocols 
included in the discussion. For secure use of the SIGTRAN protocols, 
readers should go through the "Security Considerations for SIGTRAN 
Protocols" [RFC3788]). According to that document, the use of the 
IPsec is the main requirement to secure SIGTRAN protocols in the 
Internet, but Transport Layer Security (TLS) is also considered a 
perfectly valid option for use in certain scenarios (see [RFC3436] 
for more information on using TLS with SCTP). Recommendations of 
usage are also included. 


6. Informative References 


[ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End 
Network Path Properties", Proc. SIGCOMM’99, 1999. 


[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 
Zhang, L., and V. Paxson, "Stream Control Transmission 
Protocol", RFC 2960, October 2000. 


[RFC3257] Coene, L., "Stream Control Transmission Protocol 
Applicability Statement", RFC 3257, April 2002. 


Coene & Pastor-Balbas Informational [Page 20] 


RFC 4166 


[RFC2719] 


[RFC3057] 


[RFC3331] 


[RFC3332] 


[RFC3436] 


[RFC3868] 


[RFC4165] 


[RFC3807] 


[RFC4129] 


[RFC3788] 


Telephony Signalling over SCTP AS February 2006 


Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 
L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, 
"Framework Architecture for Signaling Transport", RFC 
2719, October 1999. 


Morneault, K., Rengasami, S., Kalla, M., and G. 
Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, 
February 2001. 


Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., 
and J. Heitz, "Signaling System 7 (SS7) Message Transfer 
Part 2 (MTP2) - User Adaptation Layer", RFC 3331, 
September 2002. 


Sidebottom, G., Morneault, K., and J. Pastor-Balbas, 
"Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) 
- User Adaptation Layer (M3UA)", RFC 3332, September 
2002. 


Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 
Layer Security over Stream Control Transmission 
Protocol", RFC 3436, December 2002. 


Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., 
Keller, J., and B. Bidulock, "Signalling Connection 
Control Part User Adaptation Layer (SUA)", RFC 3868, 
October 2004. 


George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J., 
Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer 
Adaptation Layer", RFC 4165, September 2005. 


Weilandt, E., Khanchandani, N., and S. Rao, "V5.2-User 
Adaptation Layer (V5UA)", RFC 3807, June 2004. 


Mukundan, R., Morneault, K., and N. Mangalpally, "Digital 
Private Network Signaling System (DPNSS)/Digital Access 
Signaling System 2 (DASS 2) Extensions to the IUA 
Protocol", RFC 4129, September 2005. 


Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security 
Considerations for Signaling Transport (SIGTRAN) 
Protocols", RFC 3788, June 2004. 


Coene & Pastor-Balbas Informational [Page 21] 


RFC 4166 Telephony Signalling over SCTP AS February 2006 


Authors’ Addresses 


Lode Coene 
Siemens 

Atealaan 34 
Herentals B-2200 
Belgium 


Phone: +32-14-252081 
EMail: lode.coene@siemens.com 


Javier Pastor-Balbas 
Ericsson 

Via de los Poblados 13 
Madrid 28033 

Spain 


Phone: +34 91 339 1397 
EMail: J.Javier.Pastor@ericsson.com 


Coene & Pastor-Balbas Informational [Page 22] 


RFC 4166 Telephony Signalling over SCTP AS February 2006 


Full Copyright Statement 
Copyright (C) The Internet Society (2006). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 


Acknowledgement 


Funding for the RFC Editor function is provided by the IETF 
Administrative Support Activity (IASA). 


Coene & Pastor-Balbas Informational [Page 23] 


